In the late 70's and early 80's, as ARPANET evolved into the Internet of today, email became a very popular, yet chaotic, application. Popular, because it was viewed as a communications technology that would revolution the way the world exchanged ideas. Chaotic, because it was implemented by countless proprietary email technologies that could not interact with each other. It quickly became clear that a protocol standard was needed to truly make email technology a universal way to exchange ideas.
Simple Mail Transfer Protocol (SMTP) was developed to be a reliable, efficient and universal way to transport mail. The SMTP model consists of two elements: mail transfer agents (MTAs) and user agents (UAs).
The mail transfer agent has two tasks:
The user agent also has two tasks:
A universal and (because data is sent over TCP) reliable email implementation is achieved through this model. Though universal, SMTP has two critical limitations:
These limitations necessitated the addition of new protocols to handle the receiving of mail. More info about the SMTP Protocol is available in the SMTP Protocol topic.
SMTP succeeded in implementing universal, reliable and efficient email transfer. However, the lack of a final "pick up" point resulted in undesirable sustained connections. Post Office Protocol (now in its third version and commonly called POP3) was implemented to provide a common system for queuing and delivering mail to the user agent (client). This protocol called for the creation of a "mail-drop" on the mail server, in which mail, delivered by SMTP, would be placed and held for pickup by the recipient. POP allows a user agent to interface with the mail drop, in the form of logging in, downloading messages and logging out. The implementation of POP was a success, as it did not require the entire mail transfer system to be persistently connected and resident.
The combination of SMTP and POP works well, but is not perfect. The ability to transfer non-ASCII data, and a sophisticated way to manipulate email on the server are still missing. Solutions to these problems were found in the development of Multipurpose Internet Mail Extensions (MIME) and Internet Message Application Protocol (IMAP).
More info about the POP protocol is available in the POP Protocol topic.
The development of MIME grew from the extreme limitations of sending only 7-bit ASCII text, especially with the advent of multimedia files. Prior to MIME, sending non-ASCII files was a challenge, as most files are naturally 8-bit. MIME provides a new way to structure messages, as well as algorithms for encoding 8-bit data so that non-ASCII files can be transported.
More info about the MIME is available in the MIME Overview topic.
POP, while useful in its current function, is still lacking in several areas. POP does not allow for manipulation of email still on the server or for accessing mail from more than one computer (with POP, messages are typically deleted from the mail server after download). IMAP allows messages to be managed through the use of server "mailboxes," which are functionally equivalent to local folders or directories. The user agent has the ability to create, delete and rename mailboxes. It can also move email to different mailboxes, download email, and delete email. Since mail remains on the server, IMAP also allows access from different computers. IMAP is clearly a more sophisticated protocol than POP, but not all mail servers support IMAP, so POP is still very prevalent today.
More info about the IMAP protocol is available in the IMAP4 Protocol topic.
Today's email model is a hybrid of SMTP, POP, IMAP and MIME (as well as many other technologies). SMTP is used to send messages. POP is used to queue messages on the receiver mail server for downloading. IMAP is used to store messages on the receiver's mail server for server side manipulation. MIME specifies a method of sending non-ASCII data.